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J-^. (57) Abstract: The invention relates to a method for automatic recovery of UML model requirements and the updating thereof. 
According to one aspect of the invention, requirements are created while the UML model elements are created; when the model is 
stabilized, said requirements are exported towards the requirement management tool; a navigation model containing all UML objects 



OS 



pointed by at least one requirement and a requirement module of level n which can in turn be linked to other requirement models . 
The link with the upstream requirement module level n+1 can be automated with the aid of the Doors Trek Create links by Key utility. 



IT) 

(57) Abrege : La presente invention est relative a un procede de remontee automatique des exigences de modeles UML et de leur 
mise a jour, et selon une caracteristique de 1 'invention, on cree les exigences lors de la creation des elements du modele UML, 
que, lorsque le modele est stabilise, on l'exporte vers l'outil de gestion d'exigences, on cree ainsi, automatiquement, un module de 
navigation contenant tous les objets UML pointes par au moins une exigence et un module d'exigences de niveau n pouvant lui-meme 
etre lie par la suite a d'autres modules d'exigences. En particulier le lien avec le module d'exigence amont de niveau n+1 pourra etre 
automatise grace l'utilitaire DOORS TREK « Create links by key ... ». 
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PROCEDE DE REMONTEE AUTOMATIQUE DES EXIGENCES DE 
MODELES UML ET DE LEUR MISE A JOUR 

La presente invention se rapporte a un procede de remontee automatique des 
5 exigences de modeles UML crees par un outil de modelisation, et de leur mise a jour. 

Lorsque l'on mod61ise un projet, quel qu'il soit, on utilise actuellement, de 
fa<j on preferentielle le langage UML, mis en oeuvre dans un outil de modelisation, tel 
que « RHAPSODY » de la societe I-LOGIX. La modelisation necessite la prise en 
compte d'exigences, et a cet effet, on dispose d'un outil de gestion d 5 exigences tel 
10 que « DOORS » de la society TELELOGIC. Toutefois, il n'existe aucun moyen 
permettant d'assurer la tragabilite des informations du modele pour en informer 
Foutil de gestion d'exigences. 

La presente invention a pour objet un procede de remontee automatique des 
exigences de modeles UML vers un outil de gestion d'exigences pour permettre leur 
15 mise a jour, et ce, sans limitation sur la pose d'exigences et leur nombre. 

Le procede conforme a l'invention est caracterise en ce que Ton cree les 
exigences lors de la creation des elements du modele UML, qu'une fois le modele 
stabilise, on exporte vers l'outil de gestion d'exigences les exigences saisies dans le 
module et l'on cree automatiquement un module de navigation contenant tous les 
20 objets UML pointes par au moins une exigence et un module d'exigences de niveau 
n. Avantageusement, on lie le module d'exigences de niveau n a un autre module 
d'exigences amont de niveau n+1 defini precedemment. 

La presente invention sera mieux comprise a la lecture de la description 
detaillee d'un mode de realisation, pris a titre d'exemple non limitatif et illustre par 
25 le dessin annexe, sur lequel : 

- la figure 1 est un bloc-diagramme simplifie d'un exemple de mise en 
oeuvre du procede de F invention, 

- la figure 2 est un diagramme illustrant la premiere importation d'un 
module UML dans un gestionnaire d'exigences, selon le procede de 

30 l'invention, 

la figure 3 est un diagramme illustrant une nouvelle importation , 
dans les memes conditions (import niveau 1) qu'en figure 2, 
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- la figure 4 est un diagramme illustrant une nouvelle importation d'un 
modele UML, mais a un niveau different (niveau 2) de celui de la 
figure 3, 

- la figure 5 est un diagramme illustrant la pose automatique de liens 
5 de tra?abilite depuis le module vers d'autres modules DOORS selon 

le procedS de rinvention, 

- la figure 6 est un diagramme en quatre etapes, illustrant les operations 
successives intervenant lors d 'une nouvel le iteration d' import d'un 
module UML dans un gestionnaire d'exigences, selon le procede de 

10 l'invention, et 

- les figures 7 et 8 sont des diagrammes montrant deux 6tats d'un 
module d'Exigences du gestionnaire d' exigences, respectivement 
avant et apres une nouvelle importation, selon le procede de 
Tinvention. 

15 On a represents en figure 1 les principaux elements de l'architecture du 

systeme mettant en oeuvre Tinvention. Ces elements sont : un modeleur UML (1), 
qui est, de preference, Toiatil « RHAPSODY », un outil (2) de gestion d'Exigences 
UML, qui est, dans le cas present, l'outil « DOORS , un atelier d'utilitaires (3), qui 
est ici « DOORS Custom » de la societe THALES AVIONICS » et un connecteur 
20 universel de connexion inter-outils (4) « PAPEETE » (faisant l'objet d'une demande 
de brevet de la societe THALES). L'importation de modeles UML dans F outil 
DOORS depuis l'outil RHAPSODY se fait de la maniere suivante. 
Lors de la premiere importation d'un moddle UML de RHAPSODY vers DOORS 
(voir figure 2), il y a creation de deux modules dans DOORS: 
25 - Un module (5) d'Exigences UML DOORS correspondant au niveau de 

specification (niveau 1 pour Texemple repr6sent6). Ce module de DOORS 
contient l'ensemble des Exigences UML DOORS qui represented les 
Exigences UML stereotypees avec le niveau de specification choisi lors de 
1' importation. Ce module 5 contient ici les exigences de niveau 1 du module. 
30 Ces exigences sont, pour cet exemple : HLR 01, LLR 01 et HLR 03. 
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- Un Module de navigation UML (Surrogate Module UML) (6) : ce module de 
DOORS contient une representation de l'ensemble des elements UML du 
module cree dans RHAPSODY. Cette representation est sous forme de 
reference vers les elements UML. Ce module a comme objectif de permettre 
5 la navigation entre RHAPSODY et DOORS (comme expose dans le manuel 

« DOORS Custom User Guide »). 
Les importations suivantes du meme module UML peuvent etre de deux types 
differents. Soit, comme represente sur Pexemple de la figure 3, il s'agit du meme 
niveau de specification que precedemment (niveau 1 en l'occurrenee). Dans ce cas, a 
10 la fois le Module d'Exigences UMLJDOORS et le Module de navigation UML sont 
mis a jour en fonction des modifications apport^es au modele UML. Soil, comme 
represents en figure 4 3 ils portent sur un niveau de specification different (niveau 2 
en l'occurrenee, pour lequel il s'agit des exigences HLR 02 et LLR 02 ) . Dans ce 
cas, il y a creation d'un module d'Exigences UML_DOORS correspondant au niveau 
15 de specification selectionne (niveau 2) lors de l'importation et mise a jour du Module 
de navigation UML en fonction des modifications apport6es au modele. 

Les liens entre une Exigence UML-DOORS et sa representation dans le Module 
de navigation UML sont crees automatiquement lors de Pimportation du modele 
UML sous DOORS. Ces liens permettent la navigation entre . les deux outils 
20 RHAPSODY et DOORS. 

La creation de liens vers d'autres modules d'exigences DOORS est realis6e de la 
fa?on suivante. Apres avoir effectue une importation d'un modele RHAPSODY dans 
DOORS, il est possible de creer automatiquement les liens entre des Exigences du 
module cree automatiquement et des Exigences d'un autre module DOORS ou celles 
25 d'un autre module cree automatiquement anterieurement. Cette creation automatique 
de liens est effectu6e avec l'utilitaire DOORS TREK « Create links by key . . . ». 
Ainsi, comme represente en figure 5, lors de Pimportation du niveau de specification 
X 3 on cree des liens de tra?abilit6 entre le module d'Exigences de niveau X et, d'une 
part, le module d'exigences de niveau X-l, et d' autre part un module de niveau de 
30 specification d'exigences tout a fait autre (SSS dans ce cas) . 
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La gestion des modifications apportees aux exigences relatives au modele UML 
est realisee de la fagon suivante. 

La gestion des modifications des exigences sous-entend la capacite de naviguer 
entre l'outil RHAPSODY et l'outil DOORS. En effet, il faut 8tre capable d'analyser 
5 rapidement Timpact de modifications des exigences amont sur le modele UML afin 
d'appliquer les modifications adequates sur les elements mis en cause par cet impact 
et inversement. 

Pour realiser la modification d'Exigences UML DOORS, il ne faut pas modifier 
sous DOORS les attributs des Exigences UML DOORS specifiees dans les 
10 Exigences UML (comme explique dans le Guide de modelisation UML des 
exigences). Ces modifications ne doivent etre effectuees que dans le modele UML 
sous RHAPSODY. 

A la suite d'une modification d'Exigences DOORS, il faut pour chaque 
Exigence UML-DOORS qui la raffine (comme explique dans le Guide DOORS) : 
15 1 . naviguer, a l'aide de l'outil de navigation DOORS/RHAPSODY, vers ^Exigence 
UML associee, 

2. analyser l'iinpact sur la modelisation de la modification a effectuer, 

3 . mettre a jour le module 

4. mettre a jour PExigence UML dans le module, ; r ? 
20 5. importer le modele modifie sous DOORS, 

6. mettre a jour les attributs de gestion des exigences sous DOORS, 

Toute modification de module doit etre effectuee en prenant en compte les 

Exigences UML qui ont une repercussion sur les elements modifies de manidre a 

maintenir la coherence entre les Exigences UML et le modele UML. 
25 Pour ce faire, il faut consulter pour chaque element UML modifie Pensemble des 

Exigences UML qui ont une repercussion sur lui, pour verifier que ces exigences 

sont toujours cola&rentes avec la modification effectuee sur Felement 

Pour gerer les evolutions d'un module se traduisant par des modifications 

successives, on examine d'abord le mecanisme d' importations successives. 
30 L'importation d'un modele UML sous DOORS est effectuee en plusieurs etapes. Ces 

etapes sont invisibles pour rutilisateur, car elles sont effectuees en une seule fois lors 
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de Pimportation. On a illustre en figure 6 les principales etapes de ce mecanisme 
d'importations successives. Cette figure comporte quatre diagrammes (references 1 a 
4)- 

A Petat initial (1), on a, dans DOORS, un module Exigences UMLJDOORS lie 
5 a un module de navigation UML (par des liens de navigation), ces modules generes 
automatiquement lors d'un import anterieur sont qualifies d' « anciens ». 

Lorsqu'arrive une demande d'importation du modele UML visant une mise a jour 
de ces deux modules, les actions suivantes sont engagees : 
creation de deux nouveaux modules (2): 
10 o un Module Exigences UMLJDOORS contenant Pensemble des 

Exigences UMLJDOORS correspondant a toutes les Exigences UML 
contenues dans le nouveau modele UML importe, 
o un module de navigation UML representant le nouveau moddle UML, 
suppression de Pancien module de navigation UML et de tous les elements 
15 DOORS le concernant. (3), 

- analyse des mises a jour a effectuer entre les deux Modules Exigences 
UMLJDOORS, 

- mise a jour de Pancien Module Exigences UMLJDOORS (4), 
rfr* - suppression du nouveau Module Exigences UMLJDOORS 44), 

20 - creation des liens de navigation entre Pancien Module Exigences 

UMLJDOORS et le nouveau Module de navigation UML. 
L'utilisateur doit ensuite mettre a jour les liens de tragabilite avec les exigences 
amont Cette etape n'est pas incluse dans Pimportation du modele UML, mais doit 
etre effectuee separement aprds chaque importation a Taide de Putilitaire DOORS 
25 TREK « Create links by key ... ». 

La gestion des evolutions peut concerner ensuite Pajout d'exigences. Si Pon 
ajoute une Exigence UML dans le modele, il y aura, lors de Pimportation suivante, 
pour un meme niveau de specification, et un meme modele UML, creation d'un 
nouvel objet DOORS dans le Module de navigation UML et dans le Module de 
30 navigation UML correspondents. 

A titre d'exemple simplifie, on a represente en figure 7 Petat du Module 
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Exigences UML_DOORS avant une nouvelle importation, et qui comporte les 
Exigences EXI01 a EXI_04 (en version vl). On a represent© en figure 8 Fetat de ce 
Module apres une nouvelle importation, EXI 02 etant modifiee (versions vl et v2 
coexistantes), et avec une nouvelle Exigence EXI 05 (version v2). 
5 De meme, si une Exigence UML deja importee lors d'une precedente importation 

est supprimee dans le module, lors de l'importation suivante, l'Exigence UML- 
DOORS correspondant a l'Exigence UML , ne sera pas supprimee du Module 
Exigences UMLJOOORS, mais prendra le statut « OBSOLETE » et tous ses liens 
DOORS seront detruits. 
10 Si une Exigence UML deja importee lors d'une precedente importation est 

modifiee dans le modele, il y aura, lors de l'importation suivante, : 

- creation d'une nouvelle Exigence UML-DOORS correspondant a l'Exigence 
UML 

- creation d'un lien entre Pancienne et la nouvelle Exigence UML-DOORS 

15 - transfert des liens entrants et sortants de Fancienne vers la nouvelle Exigence 

UML-DOORS 

- mise a jour du numero de version sur la nouvelle Exigence UML-DOORS 
par rapport a rancienne. 

On obtient ainsi un historique des modifications d' exigences. 

20 En conclusion, le procede de l'invention permet de remonter 

automatiquement sous DOORS toutes les informations de tra$abilit6 rentrees dans le 
moddle UML. II organise automatiquement sous DOORS tout le processus 
necessaire a la navigation entre les deux outils via le connecteur PAPEETE ou un 
lien XML (ou equivalent) . Enfin il organise automatiquement toute la mise a jour 

25 des modules lors des differentes evolutions du module UML. 
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REVENDICATIONS 



1. Precede de remontee automatique des exigences de modules UML 
5 creees par un outil de modelisation, et de leur mise a jour 9 caracterise 

en ce que Ton cree les exigences lors de la creation des 616ments du 
module UML, que, lorsque le module est stabilise, on exporte vers 
l'outil de gestion d' exigences les exigences saisies dans le module, et 
que Ton cr6e , automatiquement, un module de navigation contenant 
10 tous les objets UML pointes par au moins une exigence et un module 

d'exigences de niveau n. 

2. Precede selon la revendication 1, caract6ris6 en ce qu'on lie le 
module d'exigences de niveau n a un autre module d'exigences 
amont de niveau n+1 defini pr£c6demment 

15 3. Precede selon la revendication 1 ou 2, caracterise en ce que, lors de 

modifications d'exigences, on effectue ces modifications dans le 
modele UML, avec l'outil de modelisation. 

4. Precede selon Tune des revendications precedentes, caracterise en 
ce que l'outil de modelisation est « RHAPSODY » et que l'outil de 

20 gestion des exigences est « DOORS ». 

5. Precede selon la revendication 4, caracterise en ce que lors 
d' importations successives, on realise les etapes suivantes : 

- creation de deux nouveaux modules : 

■ un Module Exigences UML_DOORS contenant Pensemble 
25 des Exigences UMLDOORS correspondant a toutes les 

Exigences UML contenues dans le modele UML importe, 

■ un module de navigation UML representant le nouveau 
moddle UML, 

- suppression de l'ancien module de navigation UML et de tous les 
30 elements DOORS le concernant , 
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- analyse des mises a jour a effectuer entre les deux Modules 
Exigences UML_DOORS, 

- mise a jour de l'ancien Module Exigences UMLJDOORS, 

- suppression du nouveau Module Exigences UMLDOORS, 

5 - creation des liens de navigation entre Fancien Module Exigences 
UML_DOORS et le nouveau Module de navigation UML. 
6. Precede selon la revendication 4 ou 5, caracterise en ce que si une 
Exigence UML deja import^e lors d'une precedente importation est modifiee 
dans le module, il y aura, lors de rimportation suivante, : 
10 o creation d'une nouvelle Exigence UML-DOORS correspondant a 

l'Exigence UML 

o creation d'un lien entre l'ancienne et la nouvelle Exigence UML- 
DOORS 

o transfert des liens entrants et sortants de Pancienne vers la nouvelle 
1 5 Exigence UML-DOORS 

o mise a jour du numero de version sur la nouvelle Exigence UML- 
DOORS par rapport k Pancienne. 
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